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lThe above-entitled matter came on for hearing on Thursday, October 25, 
22007, commencing at 9:00 a.m., at the U.S. Patent and Trademark Office, 
3600 Dulany Street, 9th Floor, Hearing Room A, Alexandria, Virginia, before 
4Lori B. Allen, Notary Public. 

5 PROCEEDINGS 

6 

7 JUDGE CRAWFORD: For your information, we have Judge Horner 

8on the phone here. 

9 MR. SCHREINER: Great. 

10 JUDGE HORNER: Good morning. 

11 JUDGE CRAWFORD: Would you like to introduce? 

12 MR. SCHREINER: Yes. My name is Steve Schreiner and I'm from 
13Goodwin Procter. I'm here with my colleague Carrie Owens from Goodwin 
14Procter as well, and our client, Dr. Bill Mann from J.P. Morgan Chase. 

15 Good morning. My name is Steve Schreiner. I'm from Goodwin 
16Procter, and I'm here on behalf of our client, JP Morgan Chase Bank, in the 
17appeal of patent application 09/366135, which is titled, "Network Based 
18Financial Processing System." As I indicated earlier, I am joined with my 
19colleague, Carrie Owens, and Dr. Bill Mann from JP Morgan Chase. I do 
20have some copies of the independent claims in large font if it would be 

21 helpful to the members of the Board. 

22 JUDGE CRAWFORD: I don't need it. 

23 JUDGE FISCHETTI: Okay, thank you. 

24 MR. SCHREINER: What I'd like to do is start out with a brief 

25 summary of the background of the invention, and then go directly into the 
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1 claims and the elements or limitations in the claims that distinguish over the 
2art of record. 

3 The background problem at issue was that many financial institutions, 
4especially those that had been involved in a series of mergers and 
5acquisitions, would have a series of back-ends legacy financial account 
6processing systems. So just by way of example in the case of Chase, at one 
7point they had several different back-end, financial account processing 
8systems, depository systems. And so you had this issue that as banks 
9integrated and acquired different entities, you had all of these back-end 
lOlegacy processing systems, and there is no single point where a bank could 
1 lreceive payment transactions and know which of these back-end processing 
12systems they should be routed to. 

13 So what you have in the prior art was that very often you would have 
14a series of miscellaneous transactions or stray transactions, if you will. The 
15 spec talks about miscellaneous transactions that would be sent to an 
16operator. So, for example, it could be somebody working in India, and they 
17have all of these financial transactions. They don't know where they go, 
18where they belong; and, so what they would have to do is a manual process 
19of essentially accessing each back-end financial account process. So logging 
20into it, then providing the account number to check, okay does this 
21transaction belong with this back-end, financial account processor. No. 
22Then you go to the next one and so forth. 

23 And then once the proper back-end financial account processor was 
24identified, that operator would then manually enter the information to 
25process the transaction. So, you can imagine. It was a very laborious type 
26of a process. So what the invention did was improve this process by 
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1 creating a system where the operator could enter batches of financial 
2transactions. So that's being multiple financial transactions, and these 
3fmancial transactions would be ones that could be associated with different 
4back-end processors. 

5 So you would have a batch, and again, multiple transactions 
6associated with different back-end processors. The operator could enter 
7those and then there would be essentially an intermediary processor, which 
8the application calls the parsing processor. So it's an intermediary parsing 
9processor that would essentially receive this batch of transactions, do some 
lOvalidation and then examine the individual transactions within the batch to 
1 1 determine where these transactions should go. So that basically, examine 
12those transactions, determine which back-end processors to route the 
13individual transactions to. 

14 So you can imagine how this approach brought significant benefit to 
15the prior art approach where it was manual and where the operator really had 
16to manually go and determine which of these back-end legacy processing 
17systems should the transaction go to. So that's kind of an overview of the 
18background of the art and the solution that was provided by the invention. 
19 If you take a look at the claims, for example, referring to the appeal 
20brief, claim 93, which is on page 18, you will see in fact that the claims 
21reflect this approach that I just described in the solution. So there's a 
22plurality of financial transaction accounting systems; so those in the back- 
23end processor, as I referred to. And then in the second clause you can see 
24that there's a group of transaction data sets where each transaction data set, 
25and that's essentially the individual financial transactions. Each one is 
26associated with a specific back-end financial accounting processor. And, in 
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lfact, the claim specifically calls out that at least two of those data sets or two 
2of those financial transactions are associated with different back-end 
3accounting processors. 

4 So again, you see reflected in the claim, the idea that the operator 
5could input this batch of multiple financial transactions, some of which are 
6associated with this financial accounting processor, some of which are 
7associated with this one, and so forth. And then continuing with the claim, 
8you go to the first processing server and the second processing server, which 
9essentially correspond to the parsing process that I described. So the first 
lOprocessing server is going to do some validation, and then focusing on one 
1 lof the real points of novelty. The second processing server is going to parse 
12the individual data set within the batch in order to send them to the 
13appropriate, corresponding back-end data processor. 
14 So essentially, you know, focusing then on the differences over the 
15prior art, there's really two main things. The first is that you're entering a 
16batch of financial transactions, and those financial transactions are ones that 
17are associated with different back-end, financial account processors; and, 
18secondly that you have this intermediate PARSER processor to be able to 
19deal with these batches of transactions by validating them and then 
20examining them and determining which ones go to which back-end 
21processors. 

22 If you look at the rejection, the rejection is defective in two, main 
23respects. And I think it's notwithstanding the KSR developments that have 
24occurred since the briefing in this case. The first is that the rejection fails to 
25address the invention as a whole. It does not address the invention, 
26including all limitations. And I think that's a requirement that lives beyond 



16 



5 



17Appeal 2006-2042 

18 Application 09/366,135 

19 

1KSR. It's found in '103, the invention as a whole. It's reiterated in KSR 
2itself as well as Graham v. John Deere. And the missing limitations that I 
3just referred to, the batch of transactions associated with different back-end 
4processors and the intermediate PARSER processor, neither of those is 
5found in the art that's cited, either alone or in combination. Nor does the 
6examiner make it a KSR-type argument to bridge the gap so to speak. 
7 So to reiterate the first effect is that the rejection fails to address all 
8claim limitations. The second defect with the rejection that makes it not a 
9prima facie case of obviousness is that the primary reference of Campbell, 
lOwhich I'll talk to in a moment, teaches away from the combination with the 

1 1 secondary reference of Berger. 

12 JUDGE CRAWFORD: Now what are the limitations you say are not 
13addressed in the rejection? 

14 MR. SCHREINER: Sure. The limitations that are not addressed, the 
15examiner essentially gives kind of an omnibus-type rejection. He cites to 
16certain sections in Campbell, which is the primary reference, and then he 
17cites to certain sections in Berger, which is the secondary, but he never 
18explains. But the examiner never explains how these two references are 
19actually combined so as to arrive at the invention. So he doesn't provide the 
20explicit rationale for how he gets from these two references, how he 

21 combines them and how he arrives at the claimed invention. 

22 So he doesn't do that, and as I said, when you actually examine the 
23claims, the two features that are in the claims that are not in the art are again 
24batch processing of multiple transactions that are associated with different 
25back-end processors. 

26 JUDGE CRAWFORD: Isn't that in Campbell? 
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1 MR. SCHREINER: Well, what Campbell describes is batch- 
2processing of identical transactions. So what Campbell talks about is you 
3have a host computer; and, then you have a series of back-end mini- 
computers, if you will - one associated with each of the, let's say, regional 
5offices. 

6 And what Campbell is really all about is it's a different problem. It's 
7not about a routing system dealing with different legacy systems and so forth 
8as I have described in connection with the present invention. Campbell is 
9really concerned about duplication and redundancy of databases between 

lOthis host computer that has a host dataset or shared data bank, and then 

1 Redundancy with that with some local databases. 

12 And what Campbell goes on to describe is that at one of these remote 
13computers, you could input batch transactions. So, for example, he talks 
14about you could input 12 payment transactions. But so, what we're talking 
15about is there are 12 payment transactions all the same type, all input to the 
16same minicomputer. The invention is talking about inputting a batched 
17transaction in the transactions that are different and that would be routed to 
18different back-end processors. 

19 So it's a very different approach and, as I said, Campbell is really 
20focused on sameness; you know, using the same databases that are 
21 redundant and that back-up one another. And similarly, Campbell talks 
22about using a host computer that is duplicative or redundant with the 
23minicomputers. And the minicomputers — back-in minicomputers — are also 
24redundant. So again, you could see how the concept that Campbell is 
25focused on really focuses away from the idea of having a series of different 
26back-end processors that process different types of transactions. 
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1 So as I indicated, the two main defects is there's missing elements in 
2the rejection, and the second is the teaching away concept, that Campbell 
3teaches away both from the combination, with the secondary reference of 
4Berber, as well as it teaches away from applicants' invention. And I'll go 
5through those in a little more detail. 

6 First, starting with Campbell just to give you a little bit more 
7background on it. I touched on it. You know, Campbell is really talking 
8about a distributed computer system that has a host computer and a series of 
9remote computers; or, as Campbell calls them, minicomputers. There's a 
lOshared database up at the host computer and then each minicomputer which 
1 lwould be at regional office would have its own local database. And the idea 
12is you would continually share and update the data between the local 
13databases and this main databank at the host computer. And the 
1 minicomputers, which is really what's material if you will or relevant to the 
15claimed invention is the minicomputers in Campbell. Well, the 
16minicomputers, each are essentially to click it of one another; and Campbell 
17explicitly describes how they're redundant and one could be used in place of 
18the other. 

19 JUDGE CRAWFORD: I thought they were regional minicomputers, 
20and so that maybe the Virginia computer wouldn't have the same as the 

21 Maryland minicomputer. 

22 MR. SCHREINER: Then functionality of Campbell's minicomputers 
23is described in terms of, okay, this minicomputer would typically serve this 
24region. So Campbell talks about minicomputer 1 serves 3 states. 
25Minicomputer 2 serves 3 different states. So that's clearly there — de facto 
26place of operation or regional coverage. But Campbell goes on to explain 
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lthat the minicomputers are completely redundant in functionality, so that if 
2one minicomputer goes down, you can use a different minicomputer or you 
3could even use the host. 

4 But I think the really key thing, even going one step further beyond 
5that is if you look at one of Campbell's many computers, and you isolate it, 
6and you say okay. Here's the minicomputer and here is a batch of 12 
7payment transactions going into that minicomputer which is what Campbell 
8describes. He says, 12 to 15 payment transactions can go in there. They're 
9all the same type of payment transaction. There's no routing to other types 
1 Oof back-end payment processors. That is remotely suggested in Campbell 
1 land again I would suggest that Campbell really teaches away from the idea 
12of batch transactions involving multiple, different- types of transactions 
13going to multiple, different back-end processors. The focus is on, you know, 
14simplicity and redundancy. 

15 JUDGE HORNER: But you've still got different databases in 
16different regions with different information, different datasets in them, 
17because the customers of region 1 are going to have different data associated 
18 with them than the customers of region 2. You're just saying that the 
19functionality is redundant, not the data. Right? 

20 MR. SCHREINER: Yeah, absolutely. I completely agree. The 

21 minicomputers in Campbell, you know, what they described. As I said, 
22there's a shared databank, so that would be at the host and would have the 
23 data for everything in the system, all of the minicomputers. And each 
24minicomputer would focus on, you know, I think it's described as you know 
25 A, B and C for minicomputer 1 , and so forth. 
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1 But, again, I would suggest that the really relevant point is, you know, 
2what does Campbell do in terms of processing batch transactions; and, as I 
3 said, Campbell is very unequivocal that the transactions are all identical 
transactions. They all get input into one particular minicomputer. There is 
5no suggestion that those batches are different transactions that are going to 
6be routed to different places for different types of processing. 
7 It's just simply not there in Campbell. So, to reiterate, what Campbell 
8is missing is the batch transactions of a series of financial transactions that 
9are associated with different back-end processors, as well as the intermediate 
10PARSER that is needed to deal with that sort of batched transaction. So 
1 lthen we turn to the Berger patent, which is the secondary reference relied on 
12by the examiner, and the examiner essentially relied on Berger to show the 
13PARSER. And Berger for sure recites a parsing function in a couple of its 
14claims. But if we examine Berger in a little more detail, I think you'll see 
15that it doesn't cure the deficiencies of Campbell. So what Berger is really 
16directed to is a VeriFone, financial transaction processing system. 
17 So you have a consumer computer, the consumer submits payments 
18transactions to a merchant computer that basically examines individual, 
19single financial transactions to decide how to reformat and forward those on 
20to a payment gateway. So the salient point I think is that Berger is a single 
21transaction processor. There's nothing in Berger suggesting you'd be 
22inputting batched transactions comprising multiple different transactions that 
23would go to multiple, different back-end processors. 
24 And, secondly, the Parsing process or the intermediate Parsing 
25processor that we talked about in the claim that basically breaks down those 
26batches of transactions and routes them accordingly, etcetera, that is wholly 
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lmissing from Berger. Again, Berger's single transaction, one-in and one-out, 
2even the Parsing functionality that the examiner points to really is very 
3different from what applicant claims. Berger's Parsing is a single message 
4Parsing, so the claim talks about receiving a message, which means like a 
5transaction request. 

6 You swipe your card, and then it parses that single message to look, 
7let's say, at a single sub-field, to decide how to reformat the message and so 
8forth. What we're talking about in the claimed invention is parsing of a 
9batch of multiple transactions to grab single transactions and route them to 
lOdifferent places. So it's a different type of parsing. 

1 1 JUDGE CRAWFORD: Now, you directed our attention to claim 93 . 
12What about claim 69? It doesn't have a lot of the specifics that you're 
13talking about. It just says the parsing processing server. Isn't that shown in 
14Berger? 

15 MR. SCHREINER: No. I would suggest to the Board that claim 69 
16does have these common features that I'm referring to, which again, are a 
17batch of multiple, financial transactions, directed to different back-end 
18processors, and the parsing processor that deals with the identification and 
19routing of those. 

20 So the first point, if you look at the third clause in the claim, we've got 
21a group of transaction datasets. If you look at the specification, this is pretty 
22much what's referred to or described as being a batch. I can direct you to the 
23 specification if need be. But we've got a group of transaction datasets, each 
24being associated with this respective one of the financial transaction 
25accounting systems. So what that's saying is that each financial transaction 
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lin the batch is associated with the specific one of the back-end, financial 
2processors. 

3 And then the claim goes a step further and says that at least two of 
4those are different. So what that means is you've got a batch of financial 
5transactions and at least two out of that batch are going to go the different 
6back-end financial processors. So I think that captures the first fundamental 
7distinction that I'm pointing out. And then the second is in the last clause. 
8The parsing processing server determining if the group is correctly entered. 
9That's a validation function. I'm not really focusing on that today, and if so, 

lOeast transaction dataset is sent to that financial transaction accounting system 

1 lwith which it is associated. 

12 So what that is saying is that the parsing processing server receives 
13that batch and then looks at the individual transactions within the batch and 
14then forward them to the appropriate back-end financial accounting 
15processors that each one is associated with. And if I could turn now to just 
16some more specific defects in the examiner's position, there are some 
17refmements that were in the examiner's answer that were not contained in 
18the final office action that is the subject of appeal here. And there are 
19several defects. 

20 On the issue of the failure of the rejection to show all claim 

21 limitations, if you look at the examiner's answer, he responds to that by 
22showing that there's motivation. He cites to Campbell, the object of the 
23invention in Campbell and then objects of the invention in Berger showing 
24motivation, which of course doesn't address the issue that appellant raised, 
25which is you haven't shown all of the claim elements. So in the examiner's 
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1 answer he does not specifically respond to our point that he hasn't shown all 
2claim limitations. You know, motivation misses the boat on that point. 
3 On the issue of our point that the primary reference of Campbell 
4teaching away with combination with secondary reference of Berger and 
5 also teaching away from appellants' invention, the examiner seems to 
6confuse the doctrine of teaching away with the doctrine of non-analogous art 
7and the doctrine of inoperativeness. So appellant pointed out that Campbell 
8operates one way, and as directed to this sort of problem. And it would 
9teach away from a combination with Berger as we discussed before. The 
lOexaminer came back and cited the W.L. Gore case and what the examiner 
1 lbasically argued is that Campbell and Berger are analogous art; and, 
12therefore, that refutes teaching away. And I would submit that as a matter of 
13law those two things are distinct. I mean, you can have two pieces of art and 
14they can be analogous. They can be in the same field; but, as we have seen 
15in I think a number of cases, one of those pieces of prior art can certainly 
16still teach away despite the fact that they are in the same field or analogous 
17art. 

18 So I think the examiner made an error of law there in addressing our 
19point about teaching away. Secondly, he also talks about the concept of 
20inoperativeness in response to our points about teaching away. And, again, I 
21 would submit that that is a separate issue - inoperativeness - that is 
22separate from our point about teaching away. So in the end, we made two 
23points: one being the examiner hasn't shown how we combine these, nor 
24how they would show all of the claim limitations. He did not respond in his 
25answer with something specifically addressing that point. He focused on 
26that motivation. And then in our point about teaching away, the examiner 
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ldid not rebut our points about teaching away. Instead, he came back and 
2said teaching away if irrelevant because it's analogous art, and you haven't 
3 showed that it would be inoperative if combined. 

4 JUDGE CRAWFORD: Thank you. 

5 Judge Horner, do you have any more questions? 

6 JUDGE HORNER: I don't. Thank you. 

7 JUDGE CRAWFORD: Judge Fischetti? 

8 JUDGE FISCHETTI: No. I don't. 

9 JUDGE CAMPBELL: Thank you. 

10 MR. SCHREINER: Thank you very much. 

1 1 [The hearing was concluded.] 
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